Live regression — auto-resolve never fired on PRs that open with conflicts

ucho/PR #226 (`aaight`, opened 2026-05-02T16:51:32, base=`dev`, mergeable=CONFLICTING, mergeStateStatus=DIRTY) never had `resolve-conflicts` dispatched. The PR sat conflicting with no auto-resolution; user had to manually intervene.

Trigger config IS enabled for ucho:

```
Agent Event Enabled Parameters
resolve-conflicts scm:pr-conflict-detected yes -
```

So configuration is fine. Bug is in the matcher.

Root cause

`src/triggers/github/pr-conflict-detected.ts:32-42` hard-codes `payload.action !== 'synchronize'`:

```ts
matches(ctx: TriggerContext): boolean {
if (ctx.source !== 'github') return false;
if (!isGitHubPullRequestPayload(ctx.payload)) return false;
const payload = ctx.payload;
// Only trigger on synchronize events (when PR head is pushed/updated)
if (payload.action !== 'synchronize') return false;
return true;
}
```

PR #226 only fired `pull_request.opened` (no commits pushed since). Matcher returned `false` → `handle()` never invoked → handler's mergeability retry + dispatch path never ran. The PR is stuck conflicting until someone manually pushes a commit, which is exactly the friction we're supposed to be removing.

The existing test at lines 80-88 explicitly codified the bug (`does not match non-synchronize action` with `action: 'opened'`). This PR flips it.

The fix

One-line widen: accept `opened`, `reopened`, AND `synchronize`. All three are GitHub's "PR head is the candidate state" signals. `closed`, `edited`, `labeled`, `assigned`, `ready_for_review` correctly stay rejected.

```ts
if (
payload.action !== 'opened' &&
payload.action !== 'reopened' &&
payload.action !== 'synchronize'
) {
return false;
}
```

Why the handler body needs no changes

The handler at lines 44+ already covers all three event types correctly:

• `gateTriggerEnabled` — config check.
• `requirePersonaIdentities` + `gateCascadePersona` — only fires for cascade-bot PRs (loop-prevention).
• `gateBaseBranch` — only fires when targeting the project's base branch.
• `mergeable === null` retry loop — handles GitHub's async mergeability computation, which is most prominent on `opened`.
• Skips if `mergeable !== false` — PRs that turn out to be mergeable are safely ignored.
• `gateAttemptLimit(MAX_ATTEMPTS=2)` — prevents loops.

Cost of widening: one extra getPR API call per opened/reopened cascade-impl PR. Bounded by the cascade-persona gate.

Tests

• Replaced the inverted `does not match non-synchronize action` (the bug pin) with `matches opened action (PR Merge dev to main #226 regression pin)` asserting `true`.
• Added `matches reopened action`.
• Replaced the single `does not match closed action` with an `it.each` covering `closed`, `edited`, `labeled`, `unlabeled`, `assigned`, `ready_for_review` — confirms we narrowed the rejection set, not widened carelessly.
• 22/22 pass; 2503/2503 across unit-triggers + unit-api.

Out of scope (intentionally — flag for follow-up)

• Periodic mergeability re-check for PRs whose base branch advanced and created a new conflict without any per-PR event (long-lived PRs). Would need a periodic scan analogous to `dangling-image-cleanup.ts` lifecycle. PR Merge dev to main #226's case is solved by the simpler `opened` fix; defer.
• Filter out drafts — separate decision; current behavior on `synchronize` doesn't filter drafts either.

Test plan

• `npx vitest run --project unit-triggers tests/unit/triggers/pr-conflict-detected.test.ts` → 22/22
• `npx vitest run --project unit-triggers --project unit-api` → 2503/2503
• `npm run typecheck` clean
• `npm run lint` clean
• CI green
• Reviewer approval (@nhopeatall)
• After deploy: open a fresh cascade-impl PR known to conflict against `dev`. Within ~1 min, Loki shows `PR has merge conflicts — triggering resolve-conflicts agent` and a new `resolve-conflicts` run record appears in `cascade runs list`.
• For PR Merge dev to main #226 specifically: close+reopen (or push an empty commit) to re-fire the matcher; should auto-dispatch resolve-conflicts.

🤖 Generated with Claude Code